Control Towerを使ったガードレール展開方法
こんにちは、コンサル部の鈴木(純)です。
今回はアカウント管理者でなければ滅多に触ることがないControl Towerの環境でガードレールをOUに対して展開する手順を紹介しようと思います。
Control Towerでガードレール有効化するときのイメージを掴めると思うので、参考にしてみてください。
前提知識
Control TowerではLanding Zoneというマルチアカウントのベストプライクティスに沿ってOUとアカウントを展開することができます。その中でガバナンスを効かせるために重要となってくるのが、今回紹介するガードレールです。
ガイダンス
Control Towerのガードレールには「ガイダンス」という分類で以下3種類に分けられています。
- 必須
- 強く推奨
- 選択的
この中でも必須の項目についてはデフォルトで有効化されていますが、強く推奨、選択的の項目については手動で有効化する必要があります。
動作
また、ガードレールの分類にはガイダンスの他に以下2つの「動作」という分類も存在します。
- 予防
- 検出
予防はOrganizationsで設定されるSCPによって設定される項目で、強制的に該当の操作をさせないというガードレールの設定をすることが可能です。
検出はConfig Rulesによって設定される項目で、該当の操作を検知するガードレールを設定することが可能です。
動作の分類で注意が必要なのは、予防は「全リージョン」に適用、検出は「Control Towerが対応しているリージョン」のみ適用されるという点ですね。忘れずに覚えておきましょう。
当然Control Tower未対応のリージョンはどうするのか?という疑問が浮かぶと思いますが、そのための仕組みも提供されています。今回はあくまでControl Towerのガードレール展開手順の紹介なので、記事の紹介までに留めておきます。
Extend AWS Control Tower governance using AWS Config Conformance Packs | Amazon Web Services
ガードレール一覧
名前 | ガイダンス | カテゴリ | 動作 |
---|---|---|---|
ログアーカイブの削除を許可しない | 必須 | 監査ログ | 予防 |
ログアーカイブの保存時に暗号化を有効にする | 必須 | 監査ログ | 予防 |
ログアーカイブのアクセスログ作成を有効にする | 必須 | 監査ログ | 予防 |
ログアーカイブへのポリシーの変更を不許可にします | 必須 | モニタリング | 予防 |
ログアーカイブへのパブリック読み取りアクセスを不許可にする | 必須 | 監査ログ | 検出 |
ログアーカイブへのパブリック書き込みアクセスを不許可にする | 必須 | 監査ログ | 検出 |
ログアーカイブの保持ポリシーを設定する | 必須 | 監査ログ | 予防 |
CloudTrail への設定変更を不許可にします | 必須 | 監査ログ | 予防 |
CloudTrail イベントと CloudWatch logs を統合する | 必須 | モニタリング | 予防 |
利用可能なすべてのリージョンで CloudTrail を有効にする | 必須 | 監査ログ | 予防 |
CloudTrail ログファイルの整合性検証を有効にする | 必須 | 監査ログ | 予防 |
AWS Control Tower によって設定された CloudWatch への変更を不許可にします | 必須 | Control Tower のセットアップ | 予防 |
AWS Config 集約承認の削除を許可しない | 必須 | Control Tower のセットアップ | 予防 |
AWS Control Tower によって設定された AWS Config アグリゲーションへの変更を不許可にします | 必須 | Control Tower のセットアップ | 予防 |
AWS Config への設定変更を不許可にします | 必須 | 監査ログ | 予防 |
利用可能なすべてのリージョンで AWS Config を有効にする | 必須 | 監査ログ | 予防 |
AWS Control Tower によって設定された AWS Config ルールへの変更を不許可にします | 必須 | Control Tower のセットアップ | 予防 |
AWS Control Tower によって設定された IAM ロールへの変更を不許可にします | 必須 | Control Tower のセットアップ | 予防 |
AWS Control Tower によって設定された Lambda 関数への変更を不許可にします | 必須 | Control Tower のセットアップ | 予防 |
CloudWatch Logs ロググループへの変更を許可しない | 必須 | 監査ログ | 予防 |
Amazon SNS によって設定された AWS Control Tower への変更を不許可にします | 必須 | Control Tower のセットアップ | 予防 |
AWS Control Tower によって設定された Amazon SNS のサブスクリプションへの変更を不許可にします | 必須 | Control Tower のセットアップ | 予防 |
EBS 用に最適化されていない EC2 インスタンスタイプの起動を許可しない | 強く推奨 | オペレーション | 検出 |
EC2 インスタンスにアタッチされていない EBS ボリュームを許可しない | 強く推奨 | オペレーション | 検出 |
EC2 インスタンスにアタッチされた EBS ボリュームの暗号化を有効にする | 強く推奨 | データセキュリティ | 検出 |
RDS データベースインスタンスへのパブリックアクセスを許可しない | 強く推奨 | データセキュリティ | 検出 |
RDS データベーススナップショットへのパブリックアクセスを許可しない | 強く推奨 | データセキュリティ | 検出 |
暗号化されたストレージではない RDS データベースインスタンスを許可しない | 強く推奨 | データセキュリティ | 検出 |
RDP を介したインターネット接続を許可しない | 強く推奨 | ネットワーク | 検出 |
SSH を介したインターネット接続を許可しない | 強く推奨 | ネットワーク | 検出 |
ルートユーザーとしてのアクションを許可しない | 強く推奨 | IAM | 予防 |
ルートユーザーのアクセスキーの作成を許可しない | 強く推奨 | IAM | 予防 |
ルートユーザーに対して、MFA を有効化する | 強く推奨 | IAM | 検出 |
S3 バケットへのパブリック読み取りアクセスを不許可にする | 強く推奨 | データセキュリティ | 検出 |
S3 バケットへのパブリック書き込みアクセスを不許可にする | 強く推奨 | データセキュリティ | 検出 |
MFA なしで IAM ユーザーへのアクセスを許可しない | 選択的 | IAM | 検出 |
MFA なしで IAM ユーザーへのコンソールアクセスを許可しない | 選択的 | IAM | 検出 |
S3 バケットのクロスリージョンレプリケーションを許可しない | 選択的 | データセキュリティ | 予防 |
MFA なしで S3 バケットでの削除アクションを許可しない | 選択的 | データセキュリティ | 予防 |
バージョンが有効かされていない S3 バケットを許可しない | 選択的 | データセキュリティ | 検出 |
ガイダンスが 強く推奨 / 選択的 のものについては利用する環境に合わせて有効化するかを検討しましょう。ガードレール最新の情報はドキュメントを参照してください。
ガードレールを有効化してみる
それでは実際にControl Towerからガードレールを有効にしていきます。
Control Towerを有効化すると、ガードレールの画面がこんな感じで表示されるようになります。
必須のガイダンスになっているガードレールを確認してみると、デフォルトでCore OUが有効化されているのが確認できますね。
強く推奨のガイダンスに分類されている「EBS 用に最適化されていない EC2 インスタンスタイプの起動を許可しない」のガードレールを確認してみると組織、アカウントで有効化されていないことが確認できると思います。これはガイダンスが必須の分類ではないのでデフォルトでは有効化されないためです。
有効化したい場合は「OUでガードレールを有効にする」から有効にしたいOUを選択するだけで、その配下にあるアカウントへガードレールを展開することができます。ボタン1つでConfig RuleやSCPを展開できるのは素晴らしいですね。
OUの有効化は1つずつしかできないようなので、複数のOUを有効化したい場合は、1つずつ完了したのを確認してから行ってください。
また、他のガードレールの有効化を並行で行いたい場合でも、同じエラーが表示されるので1つ1つ地道に有効化していく必要があります。複数のガードレールを有効化したい場合、結構な時間がかかるので、時間を確保してから作業しましょう。この辺りは一括で設定変更できるようになってくれることを期待したいですね。
→現在はアップデートにより、完了を待たずに連続で有効化ができるようになりました。内部的には並列ではなくキューを処理している感じっぽいので、有効化の速度が上がったわけではありませんが、1つ1つ完了を待たなくていいのはいいですね。
有効化が完了すると、OUが無事有効化されているのを確認することができます。
アカウントはOUに紐づいているアカウントが自動で表示されるので、どのOUを有効化するのかだけ意識すれば問題ありません。今回はControl Towerで自動作成されるAuditとLog archiveのアカウントが表示されました。
ガードレールを無効にしたいとなったときには、OUを選択して「ガードレールを無効にする」から簡単にできます。
ちなみにガードレールコンポーネントの「AWS Configルール」をクリックしてみると、設定されるCloudFormationのテンプレートを確認することができます。
今回は動作が検出(Configルール)の場合でしたが、予防の場合は「サービスコントロールポリシー (SCP)」と表示が変わり、設定されているポリシーを確認することができます。
まとめ
今回初めてControl Towerのガードレールを確認しましたが、ガードレールの設定項目ごとに設定内容や適用されているOU、アカウントが一覧で確認できるのは視認性が高くていいですね。
適用に少し時間がかかる点は、ガードレール自体一度設定すれば変更することも少ないのでそれほど気にならないと思います。
ぜひControl Towerを使ってガバナンスの効いたマルチアカウント運用を実践してみて下さい。